Release CodeTruss CLI v0.2.52 - #45

Syncs the 0.2.52 source from the private monorepo, byte for byte against the monorepo git objects (169 paths compared by blob hash, 0 mismatches, 0 missing).

codetruss-cli-0.2.52.tgz
sha256 5afc2a563358f1f7dd41eaf2484dc7913e326d9e7072f0d8c5bdeb1bb77792dd

That digest was not copied into release-reference.json: pnpm release:artifact was run against this tree, resolved from this repository's own lockfile, and the rebuilt archive cmps clean against the monorepo's copy, against the monorepo's latest pointer, and against the bytes codetruss.com is serving right now. The same cmp against 0.2.51 exits 1, so the comparison is capable of failing.

The blob-hash comparison was run a second time against the pre-sync tree as a negative control: it reported 9 mismatched paths and 3 missing, and exited 1, so a sync that silently dropped a file would not have passed.

Why this one is urgent

https://codetruss.com/downloads/codetruss-cli-latest.json already advertises 0.2.52, and its releaseUrl — .../releases/tag/v0.2.52 — currently 404s, because the release does not exist yet. Tagging this merge is what makes the advertised URL resolve.

The lead correction is also a safety claim, sitting in the README inside the published tarball, that overstates what the tool protects. That is the worst direction to be wrong in, so it does not wait for a feature release.

What 0.2.52 is

Three corrections to published artifacts. No behaviour changes — the compiled bundle is unchanged apart from the version string it prints (see below).

--yes never required --allow, and the shipped README said it did. The sentence read: "Non-interactive --yes setup requires explicit --allow values." resolveAllowGlobs in packages/cli/src/setup.ts does close to the opposite: given no explicit value it adopts every conventional source directory that exists at the repository root — src, app, apps, packages, lib, components, server, client, public, test, tests, e2e, spec, docs — as <dir>/**, prints what it adopted, and continues. It refuses only when none of the fourteen exist.

That sentence invited a reader to believe an unattended run could not adopt a scope they had not chosen, and it can. The behaviour itself is deliberate and stays: an unattended run on an ordinary repository should end up protected rather than halted over glob syntax, the adopted list is printed so the decision stays auditable, no repository-wide glob is ever adopted, and the genuinely dangerous decision — trusting repository verification commands — is still withheld without --trust-verify. What was false was the documentation, so the documentation is what changed. The corrected text also names the two ways a detected scope goes wrong: it can be wider than intended, and it is blind to a source directory outside that list — on sindresorhus/ky, whose sources live in source/, --yes adopts test/** alone and leaves the entire source tree out of scope, so ordinary changes read as scope drift.

A correction to the 0.2.51 entry. That entry said the pre-commit block left "uninstalling as the only escape". The block itself reproduces; git commit --no-verify also escapes it, and did on 0.2.50. 0.2.51's published text is deliberately not edited — it is tagged, attested and served, so it stands as shipped and the 0.2.52 entry carries the correction. The 0.2.51 section of packages/cli/CHANGELOG.md is byte-identical between the two commits (4303 bytes), and the changelog diff in this PR is 69 additions, 0 deletions.

The scoring model has a reviewable diff again. packages/analyzer-engine/src/scoring.ts carried two raw NUL bytes as map-key separators inside template literals, so git classified the file as binary and 0.2.47's rewrite of deduct() rendered as Bin 5166 -> 8676 bytes, 0 additions, 0 deletions. Both separators are now written as the six-character escape; the runtime strings are identical. This commit's own diff for that file is still binary — git calls a diff binary when either side is, and the old side is — so the fix was checked directly instead: appending one line to the 0.2.52 blob and the 0.2.51 blob and diffing each against its original gives 1 0 for 0.2.52 and - - for 0.2.51. Every tracked source file in the monorepo now holds zero raw NUL bytes; the same scan at the 0.2.51 commit finds three, so the scan is capable of failing.

The bundle is unchanged

dist/cli.cjs from the 0.2.52 archive and from the published 0.2.51 archive are the same length (819902 bytes) and differ at exactly one byte offset, 670204 — the 1 in version:"0.2.51" becoming the 2 in version:"0.2.52". One differing line out of 297. Nothing in the three corrections reaches the compiled output, which is what "no behaviour changes" is supposed to mean.

Not touched

pnpm-workspace.yaml, .npmrc, pnpm-lock.yaml, package.json (root) and .github/ are unchanged — the sync never writes mirror-owned files. public/downloads/grammars/ is carried verbatim. No previously published artifact is modified: git status under public/downloads/ reports nothing outside codetruss-cli-0.2.52.* and the latest pointers, so 0.2.44 through 0.2.51 still have exactly the bytes they were attested with.

CHANGELOG.md at the root is regenerated from packages/cli/CHANGELOG.md by the same rule as before. The generator was checked by feeding it the 0.2.51 package changelog and confirming it reproduces the committed 0.2.51 root changelog byte-for-byte; run with a deliberately wrong release version it does not, so it is capable of failing. Its npm-trail sentence stays at 0.2.50, because npm view @codetruss/cli dist-tags still reports latest as 0.2.50.

Checked locally before opening

pnpm install --frozen-lockfile resolves with the lockfile untouched (the only source change to packages/cli/package.json is the version string). pnpm validate passes against this branch: typecheck, release:artifact, pnpm test (35 files, 433 tests), the deterministic-package, release-verifier and changelog-policy suites, release:verify, and test:install. The rebuilt archive reproduced 5afc2a56… exactly, and release-reference.json's three digests were each measured off the files rather than transcribed.

The release workflow's awk extraction of the changelog entry was dry-run against the regenerated CHANGELOG.md and returns 59 non-empty lines, so the release note will not be install-steps-only; the same awk for a version with no entry returns 0 bytes, which is the case the workflow refuses to publish.

🤖 Generated with Claude Code